第12回 Webpackの導入を進めたい
#第12回
Webpackとは
Wikiで # を入力すると補完する機能など
パッチを提出するというより開発方針の提案みたいな位置付けになる。
npm とは? ruby における gem + bundler
Webpack とは?
ファイルを直接持たなくて良くなる
loaderを通すことで、特定のブラウザで動かないCSSやJavascriptを変換してくれたり、SCSSを書いたりできるようになる
https://www.redmine.org/issues/6662
.js.erbは? => 今回は一旦保留(量が膨大。あんまり先走りすぎない)
なぜ、webpack を導入したいか?
現在、javascriptのライブラリ、関数等は圧縮されずに配信されている(raphaelとかjqueryとかも)。
application.css も圧縮
webpack を導入することで、mochaや jest等のunit-testを導入できる。
npm モジュールの中に、ブラウザに依存せず、DOMをテストできる仕組みもある。=> selenium とかより速い。
最終的にはstimulus(https://github.com/hotwired/stimulus-rails )を導入したい。
Stackoverflowなどで使われ始めている?
stimulus を導入することで、erb の中の javascript を外に出していきたい。
erbの中にあるjavascriptは、エディタやlintツールの支援を受けることができない。古い記法がそのままになってしまう。
stimulus 導入によって DOM探索の必要性が減るので 自然にjquery の依存度が減っていく
なぜ今?
IE11 のサポート終了のチケットが出ている。(https://www.redmine.org/issues/34978)
良い機会なのでは?
Redmineにあるチケット
https://www.redmine.org/issues/6662 jsファイルが圧縮されない
https://www.redmine.org/issues/29914#note-4
現在考えている開発の流れ
リポジトリ上にはnode_modules(ビルド後のファイル)は持たず、ビルド前のファイルのみを持つ
開発者は、開発時にyarn installでnode_modulesを作る
リリースタイミングに作られるzipファイルにはnode_modulesビルド・圧縮済みのjs/cssを含む
問題点
開発者が全員、node.js をインストールする必要がある。
Docker が普及しているので簡単といえば簡単
ビルド済みのjs/cssをリポジトリに含めるのは得策ではない。
リリースプロセスを変更しなければいけない。tar.gz や zip に固めるときはビルド済のcss、js を同梱する。
テスト環境を整える必要がある。
test/system 内にある、Seleniumを利用したシステムテストも検証が必要。
現状、添付ファイルアップロードの upload.js でテストエラーが発生している。
=> 念のため確認
エラーメッセージは"Can't verify CSRF token authenticity."
Rails5の方のujsを読み込まないといけない?
plugin が大量に死んでしまうのでは?
提案(プレゼンの方向性)
まずは、webpack の導入だけを提案する。
simpacker (https://github.com/hokaccha/simpacker ) もしくは、webpack 単体の導入を提案し、複雑なアプリにロックインされませんよ、ということを強調
webpacker は まだwebpack5 に対応していない
simpacker は、webpacker に比べて薄いラッパー。webpack5 に対応済。
webpack + webpack-dev-server 単体で、rails と連携できるかを調査してみる。
=> ファーエンドさんのBleuclairテーマでの設定例(https://github.com/farend/redmine_theme_farend_bleuclair/blob/master/webpack.config.js )が参考になるかもしれません。
application.js の中で jquery等のライブラリを window オブジェクトにつっこむことで、plugin からもjquery等が読める状況が維持される。
webpackを通すことで、特定のブラウザで動かないCSSやJavascriptを変換したり、SCSSを書けるようになったりと今後の開発を楽にできる(babel等の loader の使用)
1. 良いことがあるよ
上記のメリット
コードがきれいになり、現在一般的なツールを使っていると新しい開発者が安心して参加しやすいよ。
クラウドでredmineを提供する場合、js、cssが圧縮さていれば、転送量削減になる。
javascript をモジュール化することで公開する関数とプライベートな関数を区分できるよ
現在は、application.js に書かれている全ての関数が公開された状態。
ロード時間が早くなるよ(と言えると良いなあ……ベンチマークを入れる?)
2. (このパッチを適用しないと) 悪いことがあるよ
rails 本家に取りのこされてしまうよ
rails 本体は、ruby の中に js のコード片が残るような書き方を推奨しない方向(に見える)
link_to_function など、本家で非推奨となったメソッドがredmineのソースの中にコピーされて残っている。
過去に、redmine のコード変更を最小限にしつつ rails のバージョンを上げようとした名残か?
3. 問題は(多分)起きないよ
開発者の環境が変わるだけで、zip, tar.gz で導入しているユーザーには影響はないはず
一般のユーザーは、nodejs や yarn の導入の必要はなし。
windowオブジェクトに、jquery等をつっこめばプラグイン作者への影響もないと思われる。
jstoolbar などの言語ファイルは一つにまとめずに別のファイルにする方法があります。(lazy loading という方法)
4. 他のツールは試してみたの? webpack にする理由は?
rails 本家がwebpackを利用
webpackの支配的な地位が未来永劫保証されているわけではないがそれは他のライブラリも同じ。しかし何らかのツールは必要。
他には Parcel(https://parceljs.org/ )や Vite(https://github.com/vitejs/vite )など
vite には、手厚いrails 連携 (https://github.com/ElMassimo/vite_ruby) 機能があるけど、jquery が対応していない。(esmoduleになっている必要がある)
5. 将来のロードマップ
当初は、旧application.js の関数は全て公開。その後、リファクタリングなどの過程で公開不要と判断された関数はモジュール内にしておく.
6. 開発環境の分かりやすい説明
tohosakuさんのリポジトリ:
https://github.com/tohosaku/redmine
simpacker ブランチ
git clone の後に、yarn (or yarn install) で node_modules を導入。
development 環境では yarn webpack serve しないといけない => js を書き換えるたびに再ビルドされます
7. みんなも使ってるよ
awesome stimulus みたいなサイトを提示する。stackoverflowでは使っているらしい。
---
追加でやりたいこと
いくらアナウンスしても、yarn installが必要だと気づかない人は一定数いそう
=> Railsを起動したときにnode_modulesディレクトリが存在しないとき、「yarn installが必要です」と例外を出してあげる仕組みを増やす
これがあればGitHubからコードを直接取得している人にも伝わる。
既存のプラグインをいくつか動かし、壊れないかの検証は必要
今のところプラグイン・テーマはビルド対象外で、現在のままの予定。あとから付け足す分には可能だが、利用者側でyarn installしてもらわないといけないため微妙かなという感じ。
ベンチマーク